자바 웹 애플리케이션

서블릿은 자바 웹 애플리케이션의 핵심 구성 요소로, 클라이언트의 요청을 처리하고 동적인 웹 페이지를 생성하는 서버 측 자바 프로그램이다. 웹 서버가 HTTP 요청을 받으면, 이를 웹 컨테이너에 전달하고, 웹 컨테이너는 해당 요청을 처리할 서블릿을 호출한다. 서블릿은 자바로 작성되므로 플랫폼 독립적이며, 멀티스레딩을 지원하여 다수의 동시 요청을 효율적으로 처리할 수 있다.

서블릿의 주요 역할은 비즈니스 로직을 수행하고, 데이터베이스와 상호작용하며, 최종적으로 HTML이나 JSON 같은 형식의 응답을 생성하는 것이다. 서블릿은 javax.servlet (현재 jakarta.servlet) 패키지에 정의된 API를 구현하며, 개발자는 주로 HttpServlet 클래스를 상속받아 doGet(), doPost() 등의 메서드를 재정의하여 요청 처리 로직을 작성한다.

서블릿의 생명주기는 웹 컨테이너에 의해 관리된다. 서블릿은 최초 요청 시 한 번 초기화(init())되고, 이후 들어오는 요청들은 service() 메서드를 통해 처리되며, 애플리케이션이 종료되거나 서블릿이 제거될 때 소멸(destroy())된다. 이 생명주기 관리 덕분에 개발자는 연결 풀링이나 중요한 리소스의 초기화와 같은 작업을 효율적으로 구현할 수 있다.

서블릿 기술은 JSP의 기반이 되며, 현대의 대부분의 자바 웹 프레임워크는 내부적으로 서블릿 API를 활용한다. 스프링 프레임워크의 핵심 컴포넌트인 DispatcherServlet도 하나의 서블릿으로, 모든 들어오는 요청을 중앙에서 가로채 적절한 컨트롤러에 라우팅하는 프론트 컨트롤러 패턴을 구현한다.

JSP(JavaServer Pages)는 자바 기반의 동적 웹 페이지를 생성하기 위한 기술이다. HTML 문서 내에 자바 코드를 직접 삽입할 수 있는 스크립트 요소와 태그 라이브러리를 제공하여, 정적인 마크업과 동적인 로직을 쉽게 결합할 수 있게 해준다. 이는 순수 서블릿만으로 HTML을 출력하는 것보다 더 직관적이고 생산적인 개발을 가능하게 한다.

JSP의 핵심 동작 원리는 '번역'과 '실행'이다. 개발자가 작성한 JSP 파일은 웹 애플리케이션 서버(WAS) 내의 JSP 컨테이너에 의해 요청 시점이나 초기 배포 시점에 자바 서블릿 소스 코드로 변환(번역)된다. 이렇게 생성된 서블릿 소스는 다시 자바 컴파일러에 의해 바이트코드(.class 파일)로 컴파일된 후, 서블릿 컨테이너에서 실행된다. 따라서 최종적으로 사용자의 브라우저에 전달되는 HTML은 사실상 서블릿이 생성한 결과물이다.

JSP는 스크립틀릿(<% %>), 표현식(<%= %>), 선언문(<%! %>)과 같은 기본 스크립트 요소 외에도, 재사용 가능한 컴포넌트를 만들기 위한 커스텀 태그 기능을 제공한다. 이 기능은 이후 JSTL(JSP Standard Tag Library)로 표준화되어, 자바 코드를 직접 쓰지 않고도 반복문, 조건문, 데이터베이스 접근 등의 로직을 태그 형태로 처리할 수 있게 발전했다. 또한 액션 태그를 활용하면 다른 JSP 페이지로의 포워딩이나 자바빈즈 컴포넌트의 사용이 용이하다.

초기에는 JSP 페이지 내에 비즈니스 로직과 프레젠테이션 로직이 혼재되는 경우가 많았으나, MVC 패턴이 널리 채택되면서 JSP의 역할은 주로 뷰(View), 즉 사용자 인터페이스를 표현하는 데 집중되게 되었다. 현대의 자바 웹 애플리케이션 개발에서는 스프링 프레임워크의 스프링 MVC와 같은 프레임워크와 결합하거나, 타임리프(Thymeleaf), Facelets 같은 더 발전된 템플릿 엔진으로 대체되는 추세에 있지만, 여전히 많은 레거시 시스템에서 핵심 기술로 사용되고 있다.

웹 애플리케이션 서버(WAS)는 자바 웹 애플리케이션이 실행되는 핵심 런타임 환경이다. 웹 서버가 정적 콘텐츠를 처리하는 데 주력하는 반면, WAS는 서블릿과 JSP를 실행하여 비즈니스 로직을 처리하고 데이터베이스와 연동하는 등 동적 콘텐츠 생성을 담당한다. 이는 클라이언트-서버 모델에서 서버 측의 핵심 구성 요소로, 엔터프라이즈 애플리케이션의 복잡한 요구사항을 충족시키기 위한 다양한 서비스를 제공한다.

WAS는 웹 컨테이너 또는 애플리케이션 서버라고도 불리며, 자바 EE 또는 자카르타 EE 스펙을 구현한다. 주요 기능으로는 서블릿 생명주기 관리, 세션 관리, 연결 풀링, 트랜잭션 관리, 보안 인증 및 권한 부여, 분산 컴퓨팅 지원 등이 있다. 이를 통해 개발자는 인프라 관련 복잡한 문제보다 비즈니스 로직 구현에 집중할 수 있게 된다.

대표적인 상용 및 오픈소스 WAS 제품으로는 아파치 톰캣, 이클립스 제티, 레진, 웹로직, 웹스피어 등이 있다. 톰캣은 경량 서블릿 컨테이너로 널리 사용되는 반면, 웹로직이나 웹스피어와 같은 풀스택 애플리케이션 서버는 EJB 지원, 메시징, 클러스터링 등 더 포괄적인 엔터프라이즈 기능을 제공한다.

마이크로서비스 아키텍처와 클라우드 네이티브 개발 방식이 확산되면서, 전통적인 모놀리식 WAS의 역할도 진화하고 있다. 스프링 부트와 같은 현대적 프레임워크는 내장형 서버를 제공하여 애플리케이션을 독립 실행형 JAR 파일로 패키징하고 배포하는 방식을 선호한다. 이는 개발과 배포의 간소화를 가져왔으나, 여전히 대규모 전통적 엔터프라이즈 시스템에서는 강력한 WAS의 관리 기능과 안정성이 중요한 가치로 남아 있다.

자바 웹 애플리케이션 개발에서 빌드 도구는 소스 코드를 컴파일하고, 필요한 라이브러리를 관리하며, 최종적으로 배포 가능한 WAR 파일을 생성하는 과정을 자동화하는 핵심 도구이다. 초기에는 Apache Ant가 빌드 과정을 스크립트로 정의하는 데 널리 사용되었으나, XML 기반의 복잡한 스크립트 작성이 필요했다. 이후 등장한 Apache Maven은 프로젝트 객체 모델(POM) 파일을 중심으로 의존성 관리와 표준화된 빌드 생명주기를 도입하여 프로젝트 구조와 빌드 과정을 획기적으로 단순화했다. Maven은 중앙 저장소에서 필요한 JAR 파일을 자동으로 다운로드하여 프로젝트에 포함시키는 의존성 관리 기능으로 특히 주목받았다.

보다 최근에는 Gradle이 Groovy나 Kotlin 기반의 유연한 빌드 스크립트를 통해 선언적이고 성능이 뛰어난 빌드를 제공하며 많은 프로젝트에서 채택되고 있다. 이러한 도구들은 프로젝트에 필요한 외부 의존성을 명시하고, 해당 의존성들이 서로 호환되는 버전으로 프로젝트에 포함되도록 해결하는 의존성 관리를 핵심 기능으로 한다. 이를 통해 개발자는 수동으로 라이브러리를 다운로드하고 클래스패스를 구성하는 번거로움에서 벗어나 비즈니스 로직 개발에 집중할 수 있다.

의존성 관리의 중요한 측면은 전이적 의존성 문제를 해결하는 것이다. 예를 들어, 프로젝트가 A 라이브러리를 사용하고, A 라이브러리가 다시 B와 C 라이브러리에 의존한다면, 빌드 도구는 B와 C 라이브러리까지 자동으로 분석하여 프로젝트에 포함시킨다. Maven과 Gradle은 이러한 의존성의 전이 그래프를 관리하며, 버전 충돌이 발생할 경우 충돌 해결 전략을 적용하여 안정적인 빌드를 보장한다.

현대적인 자바 웹 애플리케이션 개발, 특히 Spring Boot 기반 프로젝트에서는 Maven이나 Gradle이 사실상의 표준으로 자리 잡았다. 이들 도구는 단순한 컴파일을 넘어 단위 테스트 실행, 정적 분석, 패키징, 원격 저장소에 배포까지 포괄하는 빌드 파이프라인을 구성하는 토대가 된다. 따라서 효율적인 자바 웹 애플리케이션 개발을 위해서는 이들 빌드 도구의 사용법과 의존성 관리 메커니즘을 이해하는 것이 필수적이다.

Spring Framework는 자바 플랫폼을 위한 오픈 소스 애플리케이션 프레임워크로, 엔터프라이즈급 자바 웹 애플리케이션 개발의 복잡성을 해소하고 생산성을 높이기 위해 널리 사용된다. 이 프레임워크는 경량 컨테이너로서 의존성 주입과 제어의 역전이라는 핵심 개념을 바탕으로, 느슨한 결합과 테스트 용이성을 갖춘 애플리케이션 구축을 가능하게 한다. 초기에는 EJB의 복잡성에 대한 대안으로 등장했으며, 시간이 지나며 웹 애플리케이션 개발을 위한 포괄적인 인프라스트럭처 지원 플랫폼으로 성장했다.

Spring Framework의 핵심 모듈은 다양한 애플리케이션 요구사항을 지원한다. Spring Core Container는 빈의 생성과 관리를 담당하는 기본 엔진이다. Spring MVC 모듈은 웹 애플리케이션 개발을 위한 MVC 패턴 구현체를 제공하며, 서블릿 API 위에서 동작한다. 데이터 접근을 위해 JDBC나 ORM 기술을 단순화하는 Spring Data Access 모듈을 포함하며, 트랜잭션 관리를 위한 일관된 추상화 계층도 제공한다.

이 프레임워크의 주요 장점은 모듈화된 설계와 확장성에 있다. 개발자는 애플리케이션에 필요한 모듈만 선택하여 사용할 수 있으며, AOP를 통한 횡단 관심사의 모듈화, 다양한 데이터 접근 기술 통합, 그리고 RESTful 웹 서비스 구축 지원 등을 통해 전반적인 개발 효율을 극대화한다. 또한, 테스트 주도 개발을 적극 지원하는 설계 철학을 가지고 있어 단위 테스트와 통합 테스트 작성이 용이하다.

Spring Framework는 지속적으로 진화하며 현대 자바 웹 애플리케이션 개발의 사실상 표준으로 자리잡았다. 이를 기반으로 한 Spring Boot는 복잡한 설정을 최소화하고 독립 실행이 가능한 애플리케이션을 빠르게 생성할 수 있게 하여 마이크로서비스 아키텍처 구축에 크게 기여하고 있다. 또한 Spring Security는 인증과 권한 부여를, Spring Cloud는 분산 시스템 구축을 위한 도구들을 제공하여 전체적인 개발 생태계를 완성한다.

자카르타 EE는 자바를 기반으로 한 엔터프라이즈 애플리케이션 개발을 위한 공식 표준 스펙 모음이다. 이전에는 썬 마이크로시스템즈와 이후 오라클이 관리하던 자바 EE로 알려져 있었으나, 2017년 이클립스 재단으로 관리 주체가 이전되면서 현재의 명칭으로 변경되었다. 이 이전은 커뮤니티 주도의 개방형 개발 모델을 강화하기 위한 목적이었다.

이 기술은 대규모, 다중 계층, 확장 가능한 소프트웨어를 구축하는 데 필요한 핵심 API와 런타임 환경을 정의한다. 핵심 구성 요소로는 웹 계층을 처리하는 서블릿과 JSP, 데이터베이스 연결을 위한 JDBC, 트랜잭션 관리, 메시징, 보안 서비스 등이 포함된다. 이러한 표준화된 스펙 덕분에 개발자는 특정 벤더의 애플리케이션 서버에 종속되지 않고 호환되는 모든 런타임 환경에서 애플리케이션을 배포하고 실행할 수 있다.

주요 구현체로는 아파치 톰캣, 이클립스 제티, 와일드플라이, 글래스피시 등이 있으며, 이들은 자카르타 EE 스펙의 전체 또는 일부를 구현한 웹 컨테이너 또는 완전한 기능의 애플리케이션 서버이다. 현대의 경량화 트렌드에 따라 스프링 프레임워크와 같은 대안이 등장했지만, 자카르타 EE는 여전히 많은 기업 환경에서 표준 플랫폼으로 사용되며, 최근에는 마이크로서비스 아키텍처에 적합하도록 모듈화와 클라우드 네이티브 지원을 강화하고 있다.

MVC 패턴은 소프트웨어 설계에서 사용자 인터페이스와 비즈니스 로직을 분리하기 위한 아키텍처 패턴이다. 이 패턴은 애플리케이션을 모델, 뷰, 컨트롤러라는 세 가지 핵심 구성 요소로 나눈다. 모델은 애플리케이션의 데이터와 핵심 비즈니스 로직을 담당하며, 뷰는 사용자에게 정보를 표시하는 사용자 인터페이스를, 컨트롤러는 사용자의 입력을 받아 모델과 뷰를 중재하는 역할을 한다.

자바 웹 애플리케이션에서 MVC 패턴은 특히 서블릿과 JSP를 활용하여 구현된다. 전통적인 접근 방식에서는 서블릿이 컨트롤러 역할을, JSP가 뷰 역할을, 그리고 자바빈이나 엔터프라이즈 자바빈과 같은 자바 클래스가 모델 역할을 담당했다. 이 구조는 비즈니스 로직과 프레젠테이션 계층을 명확히 분리함으로써 코드의 재사용성과 유지보수성을 크게 향상시킨다.

이 패턴의 주요 장점은 각 구성 요소의 책임이 명확히 구분된다는 점이다. 개발자는 모델, 뷰, 컨트롤러를 독립적으로 개발하고 수정할 수 있으며, 이는 대규모 웹 애플리케이션 개발과 협업에 매우 유리하다. 또한, 뷰(예: JSP 페이지)를 변경하더라도 모델의 비즈니스 로직에는 영향을 주지 않아, 사용자 경험 개선이나 디자인 변경이 용이하다.

현대의 주요 자바 웹 프레임워크인 스프링 프레임워크의 스프링 MVC나 자카르타 EE의 자바서버 페이스는 모두 이 MVC 패턴을 기반으로 발전했다. 이러한 프레임워크들은 개발자가 보다 편리하고 체계적으로 MVC 구조를 구현할 수 있도록 강력한 컨트롤러 매핑, 데이터 바인딩, 뷰 리졸버 등의 기능을 제공한다.

레이어드 아키텍처는 복잡한 자바 웹 애플리케이션의 코드를 논리적 계층으로 분리하여 관리하는 소프트웨어 설계 패턴이다. 이 패턴은 주로 표현 계층, 비즈니스 로직 계층, 데이터 접근 계층으로 구성되며, 각 계층은 명확한 책임을 가진다. 표현 계층은 사용자 인터페이스와 요청 처리를 담당하고, 비즈니스 로직 계층은 애플리케이션의 핵심 규칙을 구현하며, 데이터 접근 계층은 데이터베이스나 외부 시스템과의 상호작용을 담당한다. 이러한 분리는 코드의 재사용성, 유지보수성, 테스트 용이성을 크게 향상시킨다.

각 계층은 인터페이스를 통해 통신하며, 상위 계층은 하위 계층의 구현 세부 사항을 알 필요가 없다. 예를 들어, 비즈니스 로직 계층은 데이터가 JDBC를 통해 관계형 데이터베이스에 저장되는지, 아니면 다른 데이터 접근 기술을 사용하는지 알지 못한다. 이는 의존성 주입과 같은 기법을 통해 하위 계층의 구현을 런타임에 유연하게 교체할 수 있게 한다. Spring Framework와 같은 현대적인 프레임워크는 이러한 계층화를 효과적으로 지원하는 도구와 어노테이션을 제공한다.

레이어드 아키텍처를 적용할 때는 계층 간의 경계를 명확히 하고, 순환 의존성을 피하는 것이 중요하다. 일반적인 규칙으로는 상위 계층이 하위 계층을 호출할 수 있지만, 그 반대는 허용되지 않는다. 이는 아키텍처의 안정성을 보장한다. 또한, 엔터프라이즈 애플리케이션에서는 도메인 모델 계층을 별도로 두어 핵심 비즈니스 객체를 캡슐화하거나, 서비스 계층을 세분화하는 변형 패턴도 널리 사용된다.

자바 웹 애플리케이션은 개발 완료 후 배포를 위해 표준화된 형식으로 패키징된다. 이때 가장 일반적으로 사용되는 패키징 형식이 WAR 파일이다. WAR는 Web Application Archive의 약자로, JAR 파일 형식을 기반으로 하여 웹 애플리케이션에 필요한 모든 리소스를 하나의 압축 파일로 묶는다. 이 파일 내에는 서블릿 클래스, JSP 파일, HTML, CSS, JavaScript 같은 정적 웹 리소스, 라이브러리, 그리고 애플리케이션 설정 파일들이 포함된다.

WAR 파일의 내부 구조는 자카르타 EE (구 Java EE) 또는 서블릿 스펙에 의해 엄격히 정의되어 있다. 최상위 디렉토리에는 JSP와 정적 웹 페이지가 위치하며, /WEB-INF라는 특별한 디렉토리가 반드시 존재한다. 이 /WEB-INF 디렉토리 내에는 컴파일된 자바 클래스 파일이 들어가는 classes 폴더, 외부 라이브러리 JAR 파일이 위치하는 lib 폴더, 그리고 애플리케이션의 핵심 설정 파일인 web.xml(배포 서술자)이 저장된다. 이 표준화된 구조 덕분에 어떠한 호환 웹 애플리케이션 서버에서도 일관된 방식으로 애플리케이션을 인식하고 실행할 수 있다.

개발자는 아파치 메이븐이나 그레이들 같은 빌드 도구를 사용하여 소스 코드를 컴파일하고, 정의된 구조에 따라 리소스를 모아 최종 WAR 파일을 생성한다. 생성된 WAR 파일은 톰캣, 제이보스, 웹로직, 웹스피어 등의 웹 컨테이너나 애플리케이션 서버에 배포된다. 서버는 WAR 파일을 특정 디렉토리에 복사하거나 관리 콘솔을 통해 업로드하면, 자동으로 파일을 압축 해제하고 애플리케이션을 컨텍스트 경로에 배포하여 서비스를 시작한다.

이러한 WAR 패키징 방식은 애플리케이션의 이식성과 배포의 편의성을 극대화한다. 하나의 파일로 모든 구성 요소를 관리할 수 있어 버전 관리와 배포 과정이 단순화되며, 표준 구조를 따르기 때문에 개발 환경, 테스트 환경, 운영 환경 간의 일관성을 보장한다. 또한, 최근에는 web.xml 파일을 생략하고 어노테이션 기반 설정을 사용할 수 있지만, WAR 파일의 기본적인 구조와 패키징 원칙은 현대의 스프링 부트와 같은 도구에서도 내재된 채로 유지되고 있다.

배포 서술자(deployment descriptor)는 자바 웹 애플리케이션의 구성과 동작 방식을 웹 컨테이너에 알려주는 설정 파일이다. 전통적으로 web.xml이라는 이름으로 애플리케이션의 WEB-INF 디렉토리에 위치하며, XML 형식으로 작성된다. 이 파일은 서블릿, 필터, 리스너의 등록과 매핑, 세션 설정, 보안 제약 조건, 환경 변수 등 애플리케이션의 핵심적인 배포 정보를 담고 있다. 웹 애플리케이션 서버는 애플리케이션을 시작할 때 이 파일을 읽어 명시된 설정에 따라 구성 요소를 초기화하고 관리한다.

web.xml의 주요 구성 요소로는 서블릿의 선언과 URL 패턴 매핑이 있다. 개발자는 <servlet> 태그를 사용해 서블릿 클래스를 정의하고 이름을 부여한 후, <servlet-mapping> 태그를 통해 특정 URL 요청이 해당 서블릿으로 전달되도록 지정한다. 또한 <filter>와 <filter-mapping>을 사용해 요청과 응답을 가로채 전처리 또는 후처리를 수행하는 필터를 설정할 수 있으며, <listener>를 통해 웹 애플리케이션의 생명주기 이벤트를 처리하는 리스너를 등록한다.

현대의 자바 웹 애플리케이션 개발에서는 어노테이션 기반 설정이 널리 사용되면서 web.xml 파일의 필요성이 크게 줄었다. 서블릿 3.0 사양부터는 @WebServlet, @WebFilter, @WebListener 등의 어노테이션을 코드에 직접 추가함으로써 web.xml에 서술하던 내용을 대체할 수 있게 되었다. 이로 인해 많은 프로젝트에서 web.xml 파일을 완전히 생략하거나 최소한의 설정만 유지하는 경우가 많아졌다.

그러나 web.xml은 여전히 중요한 역할을 한다. 어노테이션으로 표현하기 어려운 전역적인 설정이나, 보안 역할과 제약 조건을 정의하는 <security-constraint>, 환경 변수를 설정하는 <context-param>, 에러 페이지를 지정하는 <error-page> 등의 구성은 web.xml을 통해 관리하는 것이 일반적이다. 따라서 web.xml과 어노테이션 기반 설정은 상호 보완적으로 사용되며, 복잡한 엔터프라이즈 애플리케이션의 경우 두 방식을 함께 활용한다.